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Abstract—The Philos Marketplace blockchain system is a 
proposed hierarchical blockchain architecture which allows a 
large number of individual blockchains to operate in parallel. 
These parallel chains achieve consensus among one another on 
a limited set of core operations, while allowing each on-chain 
application to manage its own data independently of others. 
This architecture addresses the scalability issues of traditional 
linear blockchains, but requires novel consensus mechanisms. 
A central feature of the Philos consensus mechanism is its 
trust algorithm, which assigns each network node a numerical 
trust value (or score) indicating the quality of recent past 
performance. This trust value is then used to determine a node’s 
voting weight at the higher levels of consensus. In this paper, we 
formally define the Philos trust algorithm, and provide several 
illustrations of its operation, both theoretically and empirically. 
We also ask whether a misbehaving node can strategically 
exploit the algorithm for its personal gain, and show that this 
type of exploitation can be universally prevented simply by 
enforcing a mild limit on the number of participants in each 
of the parallel chains. 


I. INTRODUCTION 


A blockchain is a decentralized, shared, and immutable 
digital ledger that records transactions in blocks that are 
linked together cryptographically. Beginning with Bitcoin, 
purpose-built blockchains have been proposed for a wide 
variety of applications including payment networks [1], [2], 
decentralized provision of DNS information [3], [4], gam- 
bling [5], social media [6], stablecoins [7], [8] and many 
others [9]. This early array of purpose-built blockchains was 
followed by a wave of blockchain projects which aim to 
be general-purpose in nature, allowing features like Turing- 
complete on-chain scripting and other highly customizable 
functionality [10]—[13]. 

These blockchain systems operate by defining a consensus 
mechanism, a set of rules defining how the various partici- 
pants agree on which transactions and operations are valid 
and should be included in the permanent ledger. These range 
from the computationally intensive proof-of-work systems 
pioneered by Bitcoin [1], to newer systems such as proof- 
of-stake and its many variants [14]-[16]. Central to any 
consensus mechanism must be a guarantee that blockchain 
participants are properly incentivized to participate according 
to the nominal design of the mechanism. Unfortunately, this 
type of incentive compatibility can be challenging to prove, 
and is known to be weak on Bitcoin itself as evidenced by 
the many known mining difficulty exploits [17]-[21] 
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Scalability is another significant challenge which still 
faces blockchain technology. In many currently-operating 
mainstream blockchain implementations, the entire history 
of all on-chain activity is replicated across all participating 
nodes. This leads to immense databases for very old (such as 
Ethereum, ~1 TB) or very active blockchains (such as EOS, 
which grew to ~4 TB in its first 4 months of operation). 
The blockchain scalability challenge has led to many pro- 
posed mitigation systems which use sidechains [22], database 
sharding [23], [24], and other techniques to limit the amount 
of data which must be replicated across the entire network. 

One such proposed system is the Philos Marketplace 
blockchain system [25], [26]. Philos attempts to mitigate the 
scalability problem by employing a hierarchical consensus 
model which allows a large number of individual blockchains 
to operate in parallel. Each of these individual chains is envi- 
sioned to support a single application, and to be maintained 
by a relatively small number of known network nodes which 
collectively are called a sync list through a strict synchronous 
consensus process. We will refer to these nodes as peer. 

Higher in the hierarchy, these parallel chains achieve con- 
sensus among one another on a limited set of core operations, 
while allowing each on-chain application to manage its own 
data independently of others. Thus, the data maintained by 
a particular parallel chain need not be completely replicated 
across the entire network of parallel chains, while cross-chain 
transactions can still be executed and validated at a global 
network level. This architecture addresses the scalability 
issues of traditional linear blockchains, but in doing so it 
requires novel consensus mechanisms. 

To address this need, this paper presents the Philos Trust 
Algorithm, a decentralized means of assigning a trust value 
or reliability score to each participating peer; a peer’s trust 
value is then used to determine its weight in the on-chain 
consensus mechanisms. In this paper, we provide the first 
formal description of the Philos Trust Algorithm, provide 
several examples to illustrate its functioning, and analytically 
prove several important properties that it possesses. First, 
we show that there is a fundamental upper bound on the 
trust value which a peer can only achieve by following the 
protocol exactly. That is, if a peer deviates from the protocol 
in any way, this necessarily results in reductions in the trust 
value relative to the theoretical maximum. Second, we show 
that a particular hypothetical exploit on the Philos Trust 
Algorithm can be universally prevented simply by enforcing 
a simple condition on the size of sync lists. 

The goal of this paper is twofold: First, in Section III, we 
explicitly define the algorithm which maintains and updates 
this trust value, and provide several illustrative examples 


of how this works. Second, in Section IV, we investigate 
the incentive effects of trust. Specifically, we show how to 
prevent a specific strategic exploit of the trust algorithm 
simply by limiting the maximum size of sync lists. For 
context, Section II begins with a high-level overview of the 
basic operation of the Philos system; Section III presents 
the Philos Trust Algorithm in detail and gives the examples 
and upper bound result, and Section IV gives the incentive 
compatibility results. 


I]. PHILOS MARKETPLACE BLOCKCHAIN SYSTEM 


A blockchain is a shared database that stores data in blocks 
and links them together using cryptography. Transactions 
are recorded chronologically, forming an immutable chain. 
The chronological adding of transactions to the blockchain 
has raised questions about its future scalability and energy 
consumption. Several key metrics have been analyzed to 
measure the scalability of Bitcoin with two of the most 
important performance metrics being maximum throughput 
and latency. Since transaction throughput is restrained by 
block interval and the block size, a larger block can store 
more data but it increases the propagation time. Transaction 
latency is the time for a transaction to be confirmed. The 
more transactions, the longer it takes for transactions to be 
accepted [27]. 

The Philos Marketplace Blockchain is designed with scal- 
ability in mind and does so by allowing an expandable 
system of parallel blockchains. These blockchains are loosely 
managed by a small group of trusted consortium servers 
and a complex consensus mechanism. Basic consistency 
among these parallel chains is enforced by occasional global 
consensus operations known as bridge syncs. However, most 
of the transaction activity occurs at a lower level of consensus 
on the parallel chains themselves, whose local consensus 
is enforced by regular local synchronization events called 
primary syncs. This addresses both throughput and latency 
concerns, since these local primary syncs are only occasion- 
ally propagated globally in bridge syncs, and then only as 
block hashes. Thus, scalability is improved by reducing the 
number of transactions being replicated across all peers. 

The basic server type that runs the Philos Marketplace 
blockchain is called a peer. To interact with the blockchain 
system, a peer first groups together with two or more other 
peers to form a sync list. At regularly scheduled intervals 
(typically every 10 minutes), all peers in the sync list 
collaborate to create and cryptographically sign a primary 
block, which provisionally locks in the previous 10 minutes 
of the sync list’s activity. To incorporate these provisional 
primary blocks into global consensus, the sync list must 
occasionally participate in a consensus operation with other 
sync lists; this higher-level operation is known as a bridge 
sync (typically every 8 hours). When a sync list participates 
in a bridge sync, every peer in every participating sync list 
agrees to permanently commit all provisional primary blocks 
to the global blockchain. Hence, the bridge sync is a critical 
operation. 
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Fig. 1: Primary Consensus Process: Peers in a sync list create parallel 
content blocks C’B. At specific periods called the prime step (typically 
10 minutes), these content blocks are aggregated into a primary consensus 
block P* in a process called a primary sync. Sync lists continue to perform 
primary syncs until they decide to join a bridge consensus with other sync 
lists by creating a link block L* and then join a bridge consensus block B* 
which is broadcast globally. Syncs lists can then resume activity or request 
a dissolution of the sync list. 


Illustrated in Figure 1 is the primary consensus process 
performed by the sync list to participate in a bridge sync. 
Each peer maintains a parallel blockchain consisting of 
content blocks CB which are used to create the primary block 
P*. This process is called a primary sync. The primary sync 
process continues until the sync list wishes to participate 
in the bridge sync. They do so by creating a link block 
L* which aggregates the relevant information in conjunction 
with the P* blocks and then they will join a bridge consensus 
with other sync lists, thus creating a bridge block B* which 
is broadcast globally. At the completion of the bridge sync, 
sync lists can choose to resume activity and continue to make 
content blocks or they can request a dissolution of the sync 
list to dissolve. 


While the full Philos system is considerably more complex 
and contains many features which are out of scope of this 
paper, this brief overview provides enough context to make 
the paper’s contributions clear. 


A. Assessing Peer Trustworthiness 


The Philos Marketplace blockchain employs a trust-based 
global consensus model to incentivize peers to participate 
faithfully in consensus among their individual sync lists. This 
system calculates a running trust value (or score) for each 
peer to measure reliability and responsibility at the primary 
consensus level. In turn, a peers ability to participate in 
global consensus (e.g., bridge sync) is weighted by its trust 
value. That is, a bridge block is only considered valid if it 
is signed by peers which, put together, control a minimum 
fraction of the sum of all peer trust values in the system. 
This ensures that blocks entering global consensus have been 
vetted and approved by sufficiently well-regarded members 
of the community. Accordingly, each peer is incentivized 
to maintain a high trust value (that is, participate faithfully 
in primary consensus) so that it can maximize its weight 
(essentially voting power) in the bridge consensus step. 


II. TRUST VALUE ALGORITHM 


A. Basics 


The purpose of the trust value algorithm is to provide 
a mathematical means of calculating a trust value for each 
peer indicating the level of certainty that a peer will reliably 
participate in consensus operations. Trust values will increase 
with successive successful consensus operations and will 
decrease when consensus operations are missed. 

To reward peers with an increase in trust value, the number 
of primary sync opportunities a peer has acquired since their 
last bridge sync is kept and used in the trust value algorithm. 
As long as the sync list in which a peer is associated with 
performs according to the chains consensus operation, trust 
values will increase. Simultaneously, if a sync list misses a 
primary consensus or a bridge consensus, the trust value of 
each peer in the sync list will decrease. 


B. Algorithm 


The trust value of each peer is calculated and updated 
after inclusion of the primary block in a bridge sync. The 
calculation is a recursive algorithm that incorporates a value 
for the current calculated trust as well as a decay on any 
previous trust. The idea is to reward peers for reliable 
participation in successful primary syncs. In addition, the 
trust value considers unsuccessful primary syncs by creating 
a hidden decay that is applied when the peer performs their 
next bridge consensus. This failure to complete a primary 
consensus can be either unintentional or deliberate. In either 
case, all peers within a sync list that fail to perform a 
primary consensus will realize a reduction in their trust value. 
However, over time, if an individual peer reliably performs 
successive primary syncs, this decay mechanism gradually 
reduces the penalty of old bad behavior. This allows for 
peers to be rewarded and ensures that past mistakes are not 
remembered forever and will decay over a period of time. 

Because the primary consensus is synchronous, we hence- 
forth express all measures of time in units of Primary 
Consensus intervals (or prime steps) which we index by k. 
This is a global counter indicating the number of primary 
consensus intervals that have elapsed since the creation of 
the chain. We write A to denote the max bridge interval. 
The max bridge interval represents the maximum number of 
primary syncs that can be performed by a sync list within 
the given bridge consensus interval. For ease of reference, 
we provide Table I to assist the reader in following the 
mathematical notation. We keep the mathematical description 
as general as possible, but provide a listing of reference 
parameter values in Section III-E. 

When sync list M bridges between prime steps & and k+1, 
the trust value 7; is calculated for each peer ledger 2 € M. 
This calculation uses the peer’s previous trust value T°, the 
timestamp of the peer’s most recent bridge b’., and S'jz, the 
number of successful primary syncs recently performed by 
the sync list. Given these and an exponential decay constant 
G which satisfies 0 < 6 < 1, the new trust value J; is 


TABLE I: Table of notation 


Variable Definition 
N Set of all peers 
M Sync list; MC N 
i Peer index 
bi Time stamp of peer 2’s most recent bridge as of time k 
k Block index (unit: prime step) 
A Max bridge interval 
Siu Number of successful primaries by sync list / since previ- 
ous bridge 
Ti Peer 2’s raw trust value at time k 
T; Hypothetical trust a peer would have if trust updated with 
Su = 0 
Tj Peer 2’s fractional trust value at time k 
k — bt Primary sync counter (2’s number of primary opportunities 


since it’s last bridge) 
Exponential decay constant 


5 


computed according to the following: 


i T, pe + Say min 1 (* 7“ ; (1) 


Note in (1) that the first term in the sum captures the 
decay of the old trust; a long time since the last bridge (i.e., 
a large value of k — bi) causes a larger decay of trust. The 
second term in the sum captures the reward associated with 
recent primary syncs by peer 2’s sync list; larger values of 
Sw garner larger rewards. Finally, the min{-} term penalizes 
sync lists which bridge much sooner than the max bridge 
deadline A; this is because over-frequent bridging leads to 
blockchain bloat. It should be noted that when a peer first 
joins the system, its trust value is initialized to zero. 

The trust value aims to predict the reliability of a peer to 
successfully perform primary syncs. As primary syncs are 
the basic building block of the blockchain, the reliability of 
a peer will determine the successful matching of ledgers to 
a sync list and thereby, increase the probability that bridge 
syncs can be performed. 

We define the fractional trust of peer 7 as 


Tj 
DtEN Te 
which represents the percentage of trust that peer 7 has in 
relation to the total system trust. This is the quantity of 
highest interest to a peer, since bridge consensus requires 
a minimum threshold of the total system trust. Thus, it is 


reasonable to assume that all peers desire to have a high 
fractional trust value. 





(2) 
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C. State Machine to Model Consensus Process 


The process of sync list formation, primary sync, bridge 
sync, and sync list dissolution is depicted in the state 
transition diagram depicted in Figure 2. We describe each 
state transition in detail below. For specific examples of 
timing and how these operations interact with trust values, 
see also Section III-F. 

1) Sync List Forms: This transition occurs when a set of 
unmatched peers unanimously agree to form a sync list M 
together. Once a sync list is formed, the primary sync counter 
is initialized to zero: Sj;, = O. This counter accumulates 
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Fig. 2: Peer State Machine: Peers start off in an unmatched state and 
are matched to form a sync list, and the sync list primary counter Sa, 
is initialized to zero. After matched with a sync list, peers participate in 
a sequence of (synchronous) primary or (asynchronous) bridge syncs. If a 
sync list misses a scheduled primary sync either due to deliberate sabotage 
by a peer or an unintended fault, the sync list is automatically dissolved 
and the peers are returned to the unmatched state. If a sync list performs 
a primary sync, the sync list primary counter is incremented and the peers 
continue activity. If a sync list performs a bridge sync, the trust value for 
each peer is updated and the sync list primary counter is initialized to zero. 
Sync lists can also request dissolution and be returned to the unmatched 
State. 


the number of successful primary syncs performed between 
bridging and is used in the trust value calculation (1). 


2) Primary Sync: Once peers have been matched and 
form a sync list M/, the sync list begins to add data to its 
own parallel blockchain and performs a consensus amongst 
the group creating the primary consensus (P*) block known 
as a primary sync. The protocol requires that primary syncs 
occur at every prime step k. Each time a sync list performs a 
primary sync, the primary sync counter Sy, is incremented. 
However, sync lists that do not bridge at least every A prime 
steps are penalized by resetting Sy, to 1 when the max bridge 
interval is exceeded. 


3) Bridge Sync: To lock in the primary syncs performed, 
the sync list performs a bridge sync at any time between 
primary syncs. The trust value for each peer in the sync list 
is then calculated and updated according to (1), crediting 
each peer based on Sy, and the primary sync counter is 
reset S;, = O. The sync list can continue to remain as a 
sync list and perform new primary syncs or they can choose 
to disband and return to the unmatched state. 


4) Missed Primary Sync: This transition occurs when 
an individual peer fails to participate in a primary sync, 
deliberately or not. The sync list is disbanded and the 
blockchain of each of the list’s peers is reverted to the most 
recent state locked in by the previous bridge consensus. In 
contrast, if a sync list performs a successful bridge sync, they 
can submit for a dissolution request of the sync list and be 
returned to the unmatched state, 


D. Equilibrium Trust 


Given the state transition model described in Figure 2 and 
in the previous subsection, it is possible to calculate the 
equilibrium trust value that a peer would have if it performed 
perfectly for a very long time. That is, the peer’s sync list 
never misses a primary sync, and also consistently waits 
until the max bridge interval A to perform a bridge sync. 
Furthermore, this equilibrium value is the largest trust value 
possible in the system. This is formalized in the following 
theorem: 

Theorem 3.1: If a peer 7 performs perfectly (i.e. Syy = A 
and k — bt. = A) at every time step, then the following hold: 


1) Trust asymptotically approaches the equilibrium trust 


alue of 
valu “—_ A - 
= Togs 
2) Trust increases at every bridge: if 7; < 7™, then 
Ly Le (4) 


Furthermore, regardless of the behavior of peer 2, trust never 
exceeds 7: 
i ee (5) 


The proof of Theorem 3.1 is presented in the Appendix. 


E. Calculating Reference Parameter Values 


There are several parameters that are set by the chain 
and are envisioned to be a one-time occurrence. While 
modifications may need to be made at the start of the system, 
they are not envisioned as a value that would be constantly 
updated. Table Il provides a list of reasonable numerical 
values for the chain default parameters. Here, K denotes 
the length of a prime step; that is, the time interval between 
time indices k and k +1. 


TABLE II: Table of Reference Parameters 


Parameter | Reference Value Description 
B 0.9999111696 Decay base 


Bridge should 
occur at most every 8 hours 


: 
K 10 minutes Primary sync 
occurs every 10 minutes 
m 6 months Number of months to 
reach P fraction of equilibrium trust 


Yt 90% Percent of equilibrium 
trust to be reached 


The decay base 6 is calculated by choosing how many 
months it takes for a peer to obtain a certain percentage of 
the equilibrium trust value. That is, if the chain designer 
wishes for it to take m months for a ledger to reach a trust 
value of P7T™, the required { is given by the formula 


B= (1— P) *EneneD, (6) 


The particular 6 in Table II was calculated by choosing 
that peers reach P = 90% of the equilibrium trust in m = 6 
months. In the equation for 6, the number of months m is 
converted to the number of primaries it takes to reach the 
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Fig. 3: Perfect Bridging Example: The sync list bridges at the max bridge 


intervals (1.e. between prime steps 100 and 101 and prime steps 148 and 
149). 


equilibrium trust by multiplying the number of months by 
30 days in a month, 24 hours in a day, and 60 minutes in an 
hour. 

For example, if it is desired that peers approach 90% of 
the equilibrium trust more slowly, say in one year, G would 
be calculated as follows: 


B= (1 —0.9) POHETSH , (7) 
8B = 0.9999555838. (8) 


F. Illustrative Examples 


To illustrate the operation of the Philos Trust Algorithm, 
we will analyze a sync list’s bridge process over the period 
of prime step & = 98 to k = 154 for Figure 3 and Figure 5. 
For Figure 4, we analyze a sync list’s bridge process over 
the period of prime step & = 98 to k = 113. For the 
purposes of these examples, we will assume that the sync 
list performed a successful bridge at prime step k = 52 and 
has completed every primary since that time. We offer three 
examples illustrating the sync list bridge process occurring 


e Perfect bridge process occurring at the max bridge 
interval (Figure 3), 

e Bridge process occurring too often combined with a 

missed primary sync (Figure 4), and 

e Bridge process when a sync list bridges beyond the max 

bridge interval (Figure 5). 

Finally, Figure 6 illustrates the trust calculation for an 
individual peer over a period of 365 days considering three 
different scenarios of behavior. All parameters values are 
selected as in Table H. The trust value depicted by the blue 
trace represents a peer that performs perfectly, bridging every 
8 hours and never missing a primary. The trust value depicted 
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Fig. 4: Early and Missed Bridging Example: The sync list bridges at the 
max bridge interval, between prime step 100 and 101, bridges again between 
prime step 103 and 104 (too early), misses a primary sync at prime step 
107, is returned to unmatched state, is matched with new sync list between 
prime step 109 and 110, and bridges too early between prime step 112 and 
113, 


in red represents a peer that performed perfectly for the 
first 3 months, consistently bridges too early for the next 
month (bridging every 4 hours and never missing a primary), 
misses a primary and is unmatched for one week and then 
performs perfectly for the remaining time. The trust value 
depicted by the green trace represents a peer that performs 
perfectly for the first 3 months, performs bridges after the 
max bridge interval for 1 month (bridging every 9 hours and 
never missing a primary), then performs bridges too early for 
the next month (bridging every 3 hours), and then performs 
perfectly for the remaining time. 

First, note that any of these off-nominal behaviors caused 
significant and sudden reduction in the trust value, with the 
sharpest reduction occurring when primaries were missed 
(red), followed by bridging late (green around day 100), 
followed by bridging early (red around day 100). Second, 
note that once the peers returned to perfect performance, the 
past failures are not “forgotten” immediately, but that within 
6 months, all three peers have returned to nearly the same 
perfect trust value. 


IV. INCENTIVIZING HONEST BEHAVIOR 


A. Sabotage by a Dishonest Peer 


Note that (1) shows that a peer’s trust value is a function of 
both of its own behavior (how long since it last participated 
in a bridge) and the behavior of the other peers in its 
sync list. At any time, a peer can choose not to participate 
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interval, between prime step 100 and 101. Their next bridge is past the max 
bridge interval, between prime step 152 and 153. 
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in a primary sync thereby preventing a bridge consensus 
block from occurring. Since the trust value of each peer 
in the sync list is only updated when bridging occurs, 
every peer’s trust is affected if one peer causes a primary 
consensus interval to be missed. The trust values of all the 
peers within a sync list fail to be updated when Sy, = 0. 
However, the trust value algorithm still maintains the number 
of opportunities a peer has had to make primary syncs, 
k — b%., called the primary sync counter. This value is used 
as the exponential decay exponent which will cause a higher 
decay on a peer’s previous trust value if a sync list has been 
sabotaged. Therefore, a saboteur judges the effectiveness of 
their actions by calculating the advantage they would gain 
based on what the decay would have been with a bridge, 
without the successful primaries. 

Peer 7 gauges the effectiveness of sabotage by comparing 
(1) to the value that would be recorded if trust were updated 
with Sj;y = 0. We term this the hypothetical trust, given by 


Tih BF Pn, (9) 


Analogously, we define the hypothetical fractional trust of 
peer 2 as 


Dee N Te 


To model the strategic behaviour of a peer that is consid- 
ering sabotage, we define a utility function, where the peer 
can either behave honestly H or can sabotage S. Formally, 
for a € {H,S}, the peer’s utility function is: 
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Fig. 6: Peer Trust Value Calculation as described in Section III-F: An 
individual peer’s trust value calculation over 365 days when the peer bridges 
(Blue) perfectly, (Red) perfectly, too early for 1 month, misses primary and 
is out for 1 week, perfectly from then on, (Green) perfectly, past max bridge 
interval for | month, too early for | month, perfectly rest of time. 


Mathematically, we wish to show under what conditions 
would it be unprofitable for peer 2 to sabotage their sync list. 
That is, when is U;(S) < U;(H)? 

The main question to ask is under what circumstances 1s it 
better for a peer to intentionally cause the a primary sync to 
be missed, thereby sabotaging the sync list? This question 
thus reduces to when is the peer’s hypothetical fractional 
trust greater than the peer’s fractional trust J; > 7;. 

These questions are answered by the theorem stated below 
and its corollaries. 

Theorem 4.1: Let peer i with fractional trust 7; be a 
member of a sync list M containing || total ledgers. Peer 
2 1S incentivized to be honest if and only if 


IM|F <1. (12) 

The proof of Theorem 4.1 is presented in the Appendix. 

Theorem 4.1 states that the only way a peer can gain a 
dishonest advantage is if either it has a large trust value, or 
if it is in a large sync list. Since trust values are intrinsically 
upper bounded by the equilibrium of (1) (see Theorem 3.1), 
this allows us to calculate a universal upper bound on the size 
of a sync list which guarantees no peer can dishonestly game 
the system. This upper bound is reported in the following 
corollary: 

Corollary 4.2: Let M be a sync list, and let L be the total 
raw trust in the system. If 


BE (1 6*) 
A y) 

then every peer in // is incentivized to be honest. 
We present the proof of Corollary 4.2 in the Appendix; it 
exploits the fact that the raw trust value of every peer is 
upper-bounded by 7™ as provided by Theorem 3.1. 

Furthermore, it is possible to use a similar technique to 
derive an upper bound on the size of a sync list which is 
expressed explicitly in terms of the average performance of 
the system: 

Corollary 4.3: Let M be a sync list, and let 73... be the 
total average raw trust in the system. If we relate the average 


\M|< (13) 


trust to the upper bound, then |N|T;,,,. = L and we can write 
Corollary 4.2 as 


(14) 


The fraction Ayes is the normalized average trust of the 


system and is a metric of the system performance. If this 
value is close to 1, then it can be surmised that all peers 
are performing well and we can fit almost all peers into one 
sync list and still not have any exploitation. 


V. CONCLUSIONS 


In this paper, we have presented a complete description 
of the new Philos Trust Algorithm, used to compute trust 
values for the Philos Marketplace blockchain system. We 
characterized the equilibrium the trust value calculation and 
showed that it corresponds exactly to perfect performance. 
Furthermore, we analyzed a specific strategic exploit of the 
algorithm, and showed that it can be prevented simply by 
limiting the number of participants in a sync list. Future work 
will focus on other possible exploitative behaviors, such as 
those by patient or malicious adversaries. 
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APPENDIX 
THEOREM PROOFS 


Proof of Theorem 3.1: We first prove that 7* is an 
equilibrium; we then prove that trust never exceeds 7”; 
finally, we show that trust increases at every bridge and 
complete the proof of asymptotic convergence. 

When peer i performs perfectly (i.e. Syy = A and k—b!. = 
A) then (1) becomes 


T,=T, BO +A. (15) 


Now, let 7; = 7” as defined in (3). Then substituting in (15) 


we have 


(16) 


That is, 7™ is an equilibrium point of (15). 
Now, note that we may use (3) to write A = T*(1— 64), 
and then substitute into (15) to obtain 
T, =T; B°+T*(1- 8%) 
=e a a ee ad ae) 
a7 we Se), (17) 
Whenever T* > T,, the term (1 — 64)(T* — T,) > 0, 
so (17) shows two things: first, that 7; > 7;", proving (A). 
Second, (17) shows that if a peer has perfect performance, 
then at each bridge its trust value moves a (1 — 84) fraction 
of the way towards T*. Since (1 — 8“) < 1, this ensures 
that trust remains bounded: whenever 7’, < 7, it must be 
that 7; < 7, proving (5). 
Finally, note that (4), (5) together with the Monotone Con- 
vergence Theorem prove that trust asymptotically approaches 
its equilibrium value of 7, completing the proof. al 


Proof of Theorem 4.1: Formally, we must show that there 
is no benefit for an individual peer to disband or sabotage 
the sync list preventing the sync list from successfully 
completing primary syncs. We start with an expression that 
defines an individual peer’s share of the total system trust 
or Fractional Trust. We will denote this individual peer as 
peer number | contained within a sync list M of n peers. 
Additionally, we treat 7’; constant as they are peers not 
participating in the sync list. The fractional trust is given 
by 


sn 
CS) Sa iP om djem 5 | 


where Sy is the number of successful primaries made by 
the sync list since the last bridge and 7 indexes all peers in 
the system other than those in M/. The fractional trust for 
each individual peer is based on the ratio of the individual 
peer’s raw trust to the total trust of the system. 

For simplicity, we let Ty = a T; denote the remaining 
total sync list trust value, T, = > j¢M IT; denote the 


remaining total system trust, then (18) becomes 


h= (18) 


T+ Sm 


re 
* T +(M|Su t+ Tu +T; 


(19) 


Using (19), we can write the normalized hypothetical trust 
simply by setting Say = 0: 
7 T, 


= 20 
ar a rg (20) 


By definition, peer 1 is incentivized to be honest if and 
only if 7, < 7. Using (19) and (20), 7, < 7, can be written 
as 

Ti Z T, + Sy 
M1+Iu+T,~ T,+|M|\Su+Tut+Ts 

Letting L = T; + Ty +7; which denote the total system 

trust value, then the inequality can be written as 


T; T+ Su 


(21) 


= < ——____., 22 
Lo” £L+ \M| Sig ) 
Whenever Sy > 0, (22) is equivalent to 
7 L 
eee (23) 
| 


showing that (12) holds if and only if peer | is incentivized 
to be honest. Note that since a = J, the proof is obtained. 
| 


Proof of Corollary 4.2: It was shown in Theorem 3.1 that 
for every peer 2, 7; < ee Note that (1) and (9) imply 
that T; < T;, so that ipa = x. Given this, we have that 





_ Ff 
= a , (24) 

1 
ae 26 
<i (26) 


where (24) is the definition of hypothetical fractional trust, 
(25) is the upper bound on 7} and (26) is the assumption of 


Corollary 4.2. Inequalities (24)-(26) are equivalent to 
IM|Ti < 1. (27) 


That is, Theorem 4.1 guarantees that every peer is incen- 
tivized to be honest and the proof is complete. cl 


